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INTRODUCTION 

The Department Of Defence has man- 
dated the use of Ada on upcoming projects 
involving embedded system software* NASA 
has also indicated that Ada has been base- 
lined for the Space Station project. Both 
of these decisions will require the con- 
tractor community to transition from their 
current non-Ada programming environments. 
Existing software, that is proven and 
validated, will most likely continue to be 
used during the transition period. During 
this period new Ada programs and existing 
programs in other languages may need to be 
interfaced. 

A . myriad of possibilities exits for 
the solution of the transition problem. 
One set of solutions deals with trans- 
lating the source code of the other lan- 
guage into Ada source code or the interme- 
diate langauge used by the chosen Ada 
compiler. Another solution involves a 
special interface subroutine that switches 
from the Ada run time environment to the 
run time environment of the other lan- 
guage. The latter solution will be exam- 
ined. 

The above mentioned non— Ada program- 
ming environments consist of many differ- 
ent programming languages like FORTRAN. 
PASCAL and HAL/S. While each of these 
languages is unique, they are all members 
of the ALGOL family of programming lan- 
guages and share many implementation char- 
acteristics. Therefore, an interface sub- 
routine can be analyzed for any one of 
these language and the results can then be 
extended to the remaining languages. HAL/S 
was chosen for this examination. 

The HAL/S 360 compiler which runs 
under the IBM MVS Operating System and the 
Ada compiler which runs under the IBM 
VM/SL Operating System were selected for 
this study. The primary criteria for the 
selection of the HAL/S and Ada compilers 
was that they were hosted on the same 
machine architecture. Both compilers were 
developed by Intermetrics. 
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In this section, the general issues 
involved in interfacing any two different 
high-level languages will be explored. 
This explanation will outline the direc- 
tion taken by the following sections, *nd 
should help in providing an overview of 
the intricacies involved in such an inte- 
gration. 


The Language Environment 

Along with any Programming Language 
comes a set of assumptions under which 
that language is run. This set of assump- 
tions can be called the environment of 
that language, and consists of both algo- 
rithms and data structures. While these 
may cover a variety of subject matter, 
most Algol-like language environments can 
be understood through a few basic ideas. 

The first of these basic ideas is 
known as a run-time stack. In general, 
the run-time stack is used to keep track 
of local data and register contents across 
procedure calls as the program is being 
executed. In this way, the integrity of a 
procedure can be maintained while control 
is passed to a subprocedure, and then 
restored when the subprocedure returns. 

Another of these basic ideas concerns 
the internal representation of data. For 
example, one language environment might 
use a signed magnitude representation for 
integers while another may use twos com- 
plement form. Naturally such details are 
not an interfacing concern when a calling 
procedure and the called subprocedure are 
written in the same language. However, 
care must be taken to ensure that these 
internal representations are identical 
when two different languages are involved. 

A final basic concept involves the 
managing of run-time errors, commonly 
known as exception handling. Most often, a 
language environment will provide a large 
collection of procedures called a run-time 
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library which contains the mechanisms for 
dealing with these errors. However, since 
two different languages will use two sepa- 
rate run-time libraries, an error occur- 
ring in a subprocedure of one language 
would probably not be understood by the 
calling procedure of the other language. 
This would prevent the calling procedure 
from responding to the error in a proper 
manner. 


The Basic Interface 

In light of the previous discussion, 
the interface between two distinct lan- 
guages becomes a matter of switching envi- 
ronments. To accomplish this at run-time, 
a special linking subroutine would need to 
be invoked from the run-time library of 
the calling procedure. This subroutine 
would provide the mechanism for saving the 
present environment of the calling pro- 
cedure and initiating the new environment. 
In turn, upon termination of the called 
subprocedure, this subroutine would regain 
control and reinstate the old environment. 

Ada provides an instrument for inter- 
facing with other languages called the 
PRAGMA INTERFACE directive. The sections 
that follow take into consideration the 
details necessary for implementing this 
mechanism. 


COMPARISON QE HAL/S AND ADA. ENVIRONMENTS 
Parameter Passing 

Almost every subroutine makes use of 
parameter passing, whether it accepts some 
value or values as input, or produces some 
output, or both. This process of ex- 
changing information between procedures is 
part of a language environment and thus 
will most likely vary from one language to 
another. In regards to the HAL/S and Ada 
compilers cited, the discrepancies are 
dramatic. 


The Procedure Cali 

In most cases, all parameters are 
passed through registers to the called 
subroutine. However, when there are not 
enough registers for all of the param- 
eters, another method is pursued. This 
method usually involves placing the param- 
eter in temporary storage and passing the 
address of this location instead to the 
called subprocedure. 

Both HAL/S and Ada comply with the 
conventions outlined above. However, the 
specific registers used by the two lan- 
guages to accomplish these standards are 
not the same. For example HAL/S and Ada 
use a different register for addressing 
the temporary storage area where the over- 
flow parameters are stored. In addition, 
Ada may store its parameters in more that 
one place, depending on whether or not 


they were dynamically allocated. Any 
interfacing subroutine would have to map 
one set of register conventions to the 
other and also be aware of the different 
locations where the overflow parameters 
are stored. 


The Function Call „ 

Functions, unlike procedures, return 
a value to the calling procedure. This 
value is returned via the use of a regis- 
ter. As was true with parameter passing, 
this register may contain either the ac- 
tual value or a reference to the location 
where the value is saved. Again, each 
language will use different conventions 
for returning this value. In fact, the 
HAL/S and Ada compilers cited utilize 
different registers for this purpose. 


Data Representation 

A problem related to parameter pas- 
sing arises from how each language chooses 
to represent its data types. There are a 
variety of factors involved in data repre- 
sentation including the number of bytes 
used, indexing schemes, value restric- 
tions, and the algorithm employed for 
packing the representations to save space. 
Since each language will differ in its 
methods of representation, some scheme for 
converting data between representations 
would have to be implemented before any 
interfacing would be possible. 


The Run-Time Stack 

The objective of the run-time stack 
is to keep track of the flow of a program 
during its execution; namely, to record 
the dynamic nesting of the called proce- 
dures. To accomplish this, the run-time 
stack contains the information necessary 
to describe the state of the program at 
any point during its execution. The par- 
ticulars of the run-time stack are also 
implementation dependent. 


The HAL/S Run-Time Stack 

HAL/S has a very straightforward 
approach to its run-time stack design. Its 
run-time stack is divided into stack 
frames,*' one for each procedure currently 
being executed. These stack frames are 
further divided into two sections. The 
first of these is of a constant size and 
contains the following: a register save 

area, an area for the current code base, 
and a workspace for exception handling. 
The second section is of variable size and 
is used to store the procedure’s local and 
temporary variables. The uses of these two 
sections are explained below. 

When a subprocedure is called, a new 
stack frame is created and placed onto the 
stack. The contents of all the calling 
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procedure s registers are then stored in 
the register save area of this new stack 
frame. In turn, when the called subproce- 
dure returns control to the calling proce- 
dure these stored register contents are 
replaced into their appropriate registers. 
In this way, the calling procedure's reg- 
ister contents are not violated by the 
called subprocedure. The remaining fixed 
portion of the stack frame provides the 
procedure with run-time control informa- 
tion, This information includes: the 

location of the first executable instruc- 
tion for the current procedure, a tempo- 
rary workspace, and a link to the error 
library. 

The second section of the run-time 
stack is left for the local and temporary 
variables of the subprocedure being exe- 
cuted. The size of this section varies 
from procedure to procedure depending on 
each procedure's number of local and tem- 
porary variables. The size of each proce- 
dure stack frame, however, is determined 
at compile time. So while stack frame 
sizes may vary from procedure to proce- 
dure, each procedure's particular stack 
frame size is fixed at execution time. 


The Real Time Executive 

Real time executives are used to 
synchronize and allow communication be- 
tween two independently executing pro- 
grams. Any program which depends upon 
some real world event will depend upon a 
real time executive for proper execution. 
The internal mechanisms which implement 
real time executives are nontrivial and 
vary widely among the languages that pro- 
vide real time features. Although HAL/S 
and Ada both have a powerful set of real 
time executive tools, these tools are 
unalike and they require different ap- 
proachs by the applications programmer for 
solving real time problems. Because their 
sets of real time executives are not the 
same, the HAL/S and Ada language environ- 
ments will incorporate different implemen- 
tation schemes. To interface these two 
sets of real time executives would pose an 
extremely involved challenge. 

The Run-Time Library 

Every language has a set of primitive 
utilities which it uses repetitively. This 
set of utilities is commonly called the 
run-time library. The run-time library is 
automatically linked with the program's 
object module before execution. As a re- 
sult, every procedure or subprocedure of 
the program can employ any routine pro- 
vided by the run-time library. 

Of course, each language will have a 
unique run-time library. One of the more 
significant problems arising from this 
concerns error handling. When an error 
occurs during the execution of a program, 
the problem is most often managed by a 
routine in the run-time library. If this 


were to happen in a called subprocedure of 
a different language, there would be no 
guarantee that the process used to handle 
the error would be understood by the cal- 
ling procedure. This problem is important 
because some errors may require termina- 
tion of the program. Thus, if the called 
subprocedure were to force termination 
before returning control, the calling pro- 
cedure would not be able to exit in a 
graceful manner. This could result in a 
loss of pertinent information. Addition- 
ally, similar errors may be handled with 
different levels of severity by different 
language environments. In particular, what 
may cause a HAL/S program to terminate may 
only raise an exception in an Ada program. 
This presents a formidable problem for the 
interfacing subroutine. 


SUMMARY 

Overview of an Interface Subroutine 

The interface subroutine would oper- 
ate in a straightforward manner. The rou- 
tine would first load the passed parame- 
ters into the registers. A parameter 
would be passed either by its actual value 
or by a pointer, a machine address. Veri- 
fying that the parameters were passed in 
the correct format would be the respon- 
sibility of the Ada applications program- 
mer. 

The next step in the interface sub- 
routine would be to initialize a new HAL/S 
stack frame and branch to the entry point 
of the HAL/S executable code. During exe- 
cution, calls to the HAL/S run-time li- 
brary may be made. To guarantee proper 
execution, the Ada applications programmer 
would have to include all needed HAL/S 
run-time library routines in the load 
module. Upon finishing the normal execu- 
tion of the HAL/S code, a branch would be 
made back to the linking subroutine and 
the old stack frame would be popped off 
the stack. 

Finally, the interface subroutine 
would remove the passed parameters from 
the registers. Before assigning these 
values to their appropriate memory loca- 
tions, constraint checking should be per- 
formed. Any constraint violation should 
raise an exception and the corresponding 
exception handler should be invoked at 
that time. 


Restrictions on the Interface 

Rest rictions, unfortunately, would 
have to be placed on the called HAL/S 
procedure. The interface subroutine would 
resolve as many of the differences between 
the two run time environments as possible. 
Those differences which could not be re- 
solved would result in restrictions on the 
interface. 

One restriction would involve the way 
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errors are handled. Run-time errors in 
the HAL/S executable code will not raise 
exceptions when they occur. Some of these 
exceptions could be raised by the inter- 
face subroutine when constraint checking 
is done. Other run-time errors in the 
HAL/S code would go unnoticed and the 
subsequent execution would be indeter- 
minant. Note that the called HAL/S proce- 
dure would have to have an appropriate ON 
ERROR IGNORE statement or else the HAL/S 
code could make an unsupported operating 
system call. 

Another restriction concerns the vi- 
sibility of variables. At the point of the 
HAL/S procedure call in the Ada program, 
seme of the declared variables may have 
visibility. While an Ada procedure called 
from the same point would be able to ac- 
cess these visible variables, the HAL/S 
procedure could not, Succintly, the only 
way the Ada program and the HAL/S proce- 
dure could communicate would be via the 
passed parameters. 

Yet another restriction would be that 
the HAL /S procedure could not invoke real 
time executives. Additional restrictions 
may be to limit the use of Ada real time 
executives and to circumscribe the use of 
I/O in the HAL /S procedure. The above two 
proposed limitations need further investi- 
ga tion. 
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CONCLUSION 

Interfacing two separately developed 
compilers is a complex task. The complex- 
ity arises because very few design stand- 
ards exist for compiler development. This, 
coupled with the many complicated design 
decisions inherent in compiler construc- 
tion. virtually guarantees noncompatibil- 
ity. The interface subroutine which would 
link the two different run time environ- 
ments would resolve as many of the dis- 
similarities as possible. The differences 
that could not be resolved would be re- 
sponsible for the restrictions placed on 
the interface. Albeit restrictions would 
exist, the resulting interface may be well 
worthwhile. 
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